はじめに

Google Cloud Next '23 現地参加組の田中孝明です。

Google Cloud Next はクラスメソッドからは初参加らしいので現地の雰囲気も合わせてお伝えできればと思います。

お知らせ

9/4(月) 帰国後すぐにクラスメソッド日比谷オフィスにて recap イベント開催します。ビアバッシュ交えながら現地の熱狂をお伝えできればと思いますので是非ご参加お願いします。

セッション概要

強力な可観測性戦略を持つことにより、DevOps チームは信頼性を向上させ、解決時間を短縮し、結果として速度を向上させることができます。2 番目に大きな Cloud Native Computing Foundation (CNCF) プロジェクトである OpenTelemetry を使用すると、開発チームは、テレメトリ信号を生成、収集、エクスポートするためのオープンでポータブルな標準としてツール、API、SDK のコレクションとともに提供されるメトリクス、ログ、トレースを取得できます。このセッションでは、アプリケーション パフォーマンス モニタリング（APM）、サービス レベル目標（SLO）モニタリング、根本原因分析などの一般的なユースケースを解決するために、Google Cloud で実行されているアプリケーション上で OpenTelemetry インストルメンテーションの力を実証します。

• セッションリンク
• セッション資料

セッション動画

セッション内容

3つの中核となる柱、プロトコル、インストルメンテーション、および OpenTelemetry Collector について説明。

OpenTelemetry は、Kubernetes に次いで2番目に大きい CMCFプロジェクト であり、業界の大多数の支持を受けている。

プロトコルはすべての基礎であり、柔軟性を与えるもの。

可観測性テクノロジーを導入するという決定を時間の経過とともに変更できるようになる。

我々は OpenTelemetry と Prometheus または Prometheus エコシステムに多くの時間を費やしている。

最近では Prometheus が Pushベース のメトリクスに OTLP を採用した。

OpenTelemetry の原則的なものに一つは手持ちの可観測性データは全て使用できるべきというのがある。

これはコレクターアイテムです。データを受信してエクスポートするように設計されたエージェントと同じ意味で使用する。

すべてのメトリクス、トレース、ログ、イベントに関係するものはたくさんある。

プロセッサは文字通りデータを変換するだけですが、メタデータなどの追加も含まれる。契約を通過する際に追加や重要な情報をラベルを付けれる。

個人を特定する情報を削除したい場合はホストがそれを行うことができる。

Google Cloud、Kafka、Cassandra は共通の可観測性エクスポーター。

インストルメンテーションについて。

まずどのようにデータを作成するかということ。

• レイテンシのメトリクスはどこで入手できるか
• ネットワークのメトリクスはどこで取得できるか

外部は管理インターフェイスで利用可能な値を調べ、それらをメトリクスに変換する。

元々は計測されていなかったプロセスを実際に実行できる場所であり、何かしらの方法で操作してテレメトリを直接生成するようになった。

開発者がマニュアルで生成する方法を残しているが、このレベルの労欲を費やす必要があるときはビジネスにとって重要であるべきだということ。

組織全体に Telemetry を導入できた場合は、標準化にはデータベースの作成が伴う。

すべての Telemetry の大きな目標の1つは、データを制御できるようにする。

デモで、「予定があり、オンプレミス展開を行っている」とする。

オンプレミス用のローカル可観測性ソリューションがある。だがすべてをグローバルに把握したいと考えている。

必要なデータを世界中に送信でき必要なものを保持できる。

このデモでは、オークションを行う Eコマースサイト を作成しようとした。

GKE Autopilot の マイクロサービス を使用してこれを設計している。

いくつかのユーザーの行動を調べて、ユーザーがアイテムを実行したり、請求可能なアイテムに入札したりできるマイクロサービスをいくつか用意している。

彼らはオークションを作成と終了することができ、そのような種類のものがトレースで表示されるユースケースとして現れることがわかる。

パイプラインを作成して、すべての宛先に送信する必要のないデータを除外し、送信する必要がある場所でデータを実行する機能について。

OpenTelemetry の移行方法に関する展開パターンとベストプラクティス。

最も単純な展開パターンの1つであり、最初に検討すべきパターン。

2つの Collector を持つことは可観測性にとって重要。

プロセスからできるだけ早く情報を取得できるように、ローカルなものを用意する。

現在持っているものから始める。

利用可能なアプリケーションがない場合は、環境内で最も簡単なものを選択する。

ほとんどの場合、既存のインスツルメンテーションを利用して、ワークロードを新しいパイプラインにリダイレクトできる。

すべてを一度に行う必要はない。

所感

Cloud Run も Sidecar 対応したこともあり、可観測性のツールの話は必須となってきつつあります。このセッションはデモも交えて説明されているので何度か動画を見ながら振り返りたいと思います。